ee9 V3.2 Implementation Overview 


0. Readership 

This document is intended for anyone wishing to maintain or adapt the GNU Ada KDF9 emulator, ee9. It presents a 
synopsis of the program structure, with some important points of detail highlighted. ee9 is composed of about 100 Ada 
2012 source files, each containing either the specification or the implementation of a separately-compiled module. These 
modules are described here on the basis of their specific contribution to the functionality of ee9. 

1. CPU 

1.A The fundamental register structures of KDF9: kdf 9, KDF9_char_sets, opcode_syndromes 
The KDF9 48-bit word, 24-bit halfword, 16-bit Q store field and 8-bit instruction syllable are defined in KDF9; the 6-bit 
character and its associated character sets in KDF9_char_sets. The latter is separated out so it can be included in other 
programs without dragging in the whole of KDF9 , which amounts to ~2 KSLOC. 

KDF9 uses the basic machine data types to declare structures representing the NEST, the Q Store, the SJNS, the native 
and decoded instruction types and the instruction buffers, virtual time management, and the privileged state components. 
It also implements the KDF9 interrupt system. 

The NEST is a LIFO of words, the top of the stack being indexed by a variable of type mod 19; this means that 
subtracting 1 from it when 0 wraps around to 18, while adding 1 to 18 wraps around to 0. This is a property of the Ada 
type; no conditional logic is explicitly written to achieve these effects, which exactly mirror the behaviour of the KDF9 
hardware. A similar variable of type mod 17 serves the SJNS. Operations are provided to pop, push, read and write the 
top cells of the NEST and SJNS. The read and write operations are used to avoid unnecessary push/pop overheads when 
operands are directly over-written by results. 

The NEST and SJNS operations have explicitly written pre- and post-conditions that are checked only when ee9 is 
compiled in the debugging mode. See §4. 

KDF9 had 4 sets of registers, the active set being selected by a 2-bit ‘context’ register. To avoid indexing a 2-D array on 
every register access, ee9 works with a single, fixed set of registers; changing the context swaps them, to/from a bank of 4 
sets selected by the old and new contexts. 

KDF9 instructions are of 1, 2, or 3 8-bit syllables, as indicated by the first 2 bits of the first syllable: 00 for a single 
syllable, 01 for two syllables, 10 for three-syllable jump orders, and 11 for three-syllable data fetch/store orders. To 
simplify the decoding, ee9 computes a ‘syndrome’ value from each instruction. For one syllable orders, it is simply the 
least significant 6 bits of the syllable. For two and three syllable orders, the syndrome is that value with some irrelevant 
bits masked off and perhaps some other bits from another field of the order OR-ed in. The two syllable I/O orders are 
further identified by the least significant four bits of the second syllable and these are extracted and examined separately. 
The case statements that select the emulation routine for each order are driven by these syndrome values, which are listed 
in the package KDF9 . opcode_syndromes. 

The KDF9 held 12 syllables of instruction code in its two instruction buffers, IWB0 and IWB1, and was able to execute 
short loops entirely held in those buffers without repeatedly fetching the orders from store. This behaviour is followed 
quite closely by ee9. Note, however, that ee9 does not attempt to emulate the concurrent operation of Arithmetic Control 

and Main Control (see The Hardware of the KDF9 , §7: MAIN CONTROL). 

1.B Non-trivial arithmetic: kdf9 .cpu 

Simple integer arithmetic and logical operations on words, halfwords, and 16-bit fields, are all entailed by the declarations 
of those types in KDF9, and so are available to the KDF9 .microcode package without further ado. More complicated 
operations, including 48- and 96-bit shifts, multiplication, division, 96-bit arithmetic, and single- and double-precision 
floating point arithmetic, are defined in the KDF9.CPU package. These is little to be said in general about it; 
understanding demands a close reading of its details. 

1 .C The core store: kdf 9 . store 

The implementation of the core store as an array of KDF9 words is straightforward, apart from the need to implement 
store lockouts. The procedures validate_access and validate_range_access are used before fetching or 
storing a location, and if it is found to be in a locked-out group, raise the LOV_trap exception. The latter is handled at 
the top level of control flow, in the execute procedure, which calls IOC.handle_a_main_store_lockout to 
put the lockout into effect. See §2.A. On return to execute, the emulation loop resumes. 

The KDF9 . store. ref lect procedure is used by the ‘read backwards’ operations on magnetic tapes. It transposes a 
vector of words in a range of locations. 

1.D The microcode: KDF9.microcode 

This package controls instruction decoding, operand preparation, and instruction dispatching. Although quite big (~1600 
SLOC), thanks to the design integrity of the KDF9 it is straightforward. 
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2. I/O 

2.A I/O Control and KDF9 peripherals: ioc and its descendants 

KDF9 I/O is implemented by a set of orders that address a peripheral device by means of the number, in 0..I5, of the 
‘buffer’ to which it is connected. A KDF9 buffer was in fact a DMA channel, and it was feasible for all 16 to be active 
simultaneously, the peripheral complement being such that no device could be starved of core cycles. A buffer was 
specific to the type of its device: a paper tape reader, for example, could be switched between TR buffers, but could not be 
connected to a CP buffer. In ee9, at present, the buffer number of each device is fixed at compilation time. 

ee9 invokes the correct procedure to implement an I/O operation by indexing the array IOC.buffer with the buffer 
number operand. The elements of IOC .buffer are class-wide pointers to the (statically allocated) device objects. Each 
device initializes itself on declaration, and plugs a pointer to itself into the appropriate element of IOC. buffer. That 
pointer is used to dispatch (in the Object-Oriented sense) to the method proper to the device. 

The device objects are declared within their defining package, and form an Object-Oriented type hierarchy: 

IOC. device (abstract — objects cannot be declared) 

IOC. fast. device (abstract — objects cannot be declared) 

IOC.fast.DR.device(DRum) 

IOC. fast. FD. device (Fixed Disc) 

IOC. fast. magtape. device (abstract — objects cannot be declared) 

IOC. fast.magtape.MT.deck (EE 1081 deck) 

IOC. fast .magtape. ST. deck (IBM 7-track deck) 

IOC. slow.device (abstract — objects cannot be declared) 

IOC. slow, shift.device (abstract — objects cannot be declared) 

IOC. slow, shift. FW.device (FlexoWriter) 

IOC. slow, shift.GP.device (Graph Plotter) 

IOC. slow, shift.TP.device (Tape Punch) 

IOC. slow, shift. TR.device (Tape Reader) 

IOC. slow. unit. device (abstract — objects cannot be declared) 

IOC. slow.unit.CP.device (Card Punch) 

IOC. slow.unit.CR.device (Card Reader) 

IOC. slow.unit.LP.device (Line Printer) 

These types are declared in the packages whose names are obtained by eliding ‘. device’. Each device type may declare 
some device-specific operations that over-ride and/or redispatch to operations of an ancestor type. 

Fast devices do one core cycle per word; slow devices do one core cycle per KDF9 character (called a ‘ symbol’ in ee9, 
to avoid confusion with the host computer’s Latin-1 character set). Thus their timing properties differ. Moreover, 
IOC. slow.unit devices always traverse one or more complete ‘unit records’ — cards or printed lines; whereas 
IOC. slow, shift devices traverse just as much of the external medium as is needed to convey the number of 
characters transferred. 

It is worth looking at the Initialize and Finalize procedures for each device type. At a minimum Initialize 
opens the external file that plays the role of the device in ee9. These files are named after the device type and number; e.g. 
“TR1”, “MT2”, and so on. Finalize logs some statistics on the device activity and closes the external file. More 
complex devices, such as the magnetic tapes and the drum, have rather more housekeeping to do in both Initialize 
and Finalize. 

ee9 not only emulates the data transfer for each I/O operation, it also simulates the physical time elapsed in the transfer. A 
second operation cannot be started on a buffer while it is considered to still be busy with a transfer that was previously 
initiated. The KDF9 programmer has orders — TLOQq, INTQq, and BUSYQq — that allow a program to interrogate 
the state of a transfer on a buffer; and an order — PARQq — which allows the success of a terminated transfer to be 
determined. Applying any operation other than BUSYQq to a busy device, or attempting to access the same core store 
groups as those the transfer is accessing, causes the program to be locked out until the transfer terminates. 

The IOC method that emulates an I/O instruction, in reality, effects the whole transfer immediately; then computes the 
KDF9 device’s predicted end-of-transfer (PR interrupt) time, and sets the necessary store lockouts, before returning. The 
physically immediate end of the transfer does not give rise to observable differences from the behaviour of the hardware, 
because problem-program transfers are effectively atomic, this being ensured by the lockout mechanisms. As far as a 
program is concerned, once a transfer has been initiated, its result can be inspected only after it has terminated: that is, 
only after its end-of-transfer time has been reached. 

This is not true of the Director, because lockouts are inoperative in Director state; but Directors are written to avoid any 
danger this freedom might expose them to, inter alia by explicitly setting and checking the implicated lockout registers. 
The immediately-following discussion therefore assumes that the transfer was started by a problem program that is not 
running under Director control, i.e. not in ee9’s boot mode. 
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Once started, a transfer can lead to two quite different sequences of event, depending on whether it terminates without 
other effect on the program, or leads to the program being locked out. 

If the program succeeds in running past the nearest PR time without being locked out then ee9 merely takes note of this 
fact, clearing the lockouts and setting the buffer idle. This is done in IOC. act_on_pending_interrupts, which is 
called at the end of an instruction cycle when the_elapsed_time > the_next_interrupt_time, and itself 
calls IOC. f inalize_transf er when it finds a busy buffer whose completion time has passed. 

act_on_pending_interrupts also sets a new value for the_next_interrupt_time, which is either the 
next expected PR time; or 2 64 -l if all buffers are idle; or, in boot mode, at most 1 virtual second in the future, to prevent a 
'double clock’ RESET interrupt. The KDF9 actually checked for interrupts only at certain points in its microprogram, not 
at the end of every instruction; see The Hardware of the KDF9, §7, MAIN CONTROL. ee9 is more responsive: it defers 
an interrupt only after the execution of an EXITD or an OUT instruction. 

On the other hand, if the program transgresses on a locked-out store area, or attempts another operation on a busy buffer, 
then a different logic comes into play. To model this, ee9 takes a lead from the techniques of discrete event simulation: 
the_elapsed_time is advanced to the predicted completion time of the responsible transfer, the buffer is set idle, its 
store lockouts are cleared, and execution of the problem program continues. The net effect is that the program sees the 
elapsed time as having jumped forward exactly as would have happened in reality, between its being suspended and being 
resumed. These effects are mediated by three routines in IOC: handle_a_buf f er_lockout takes the case of a busy 
device, INT takes that of the INTQq instruction, and handle_a_main_store_lockout is called by the core store 
access routines; they all invoke the procedure KDF9.advance_the_clock to update the_elapsed_time, and 
then call act_on_pending_interrupts to deal with the rest of the necessary housekeeping. 

When ee9 is working in boot mode, things happen rather differently. 

If Director is active when it is discovered that the_elapsed_time > the_next_interrupt_time then the PR 
flag is set in the RFIR (Reason For Interrupt) register; Director is not interruptible, but will eventually notice the interrupt 
request and deal with it. If a problem program is active, then all of the previously-described apparatus comes again into 
play, but instead of merely resuming the program, a PR interrupt is effected if the transfer was initiated on behalf of a 
program of higher priority than the one running. That decision is based on the contents of the Program Holdup (PHU) 
registers, allowing Director to reschedule the CPU. (To be precise, the interrupt requested will be EDT if the transfer was 
started by Director, or if the PHUs indicate a possible priority inversion over access to the interrupting buffer.) 

A lockout when running a problem program in boot mode effects a LOV interrupt: the whole issue is punted to Director. 

2.A.1 The bootstrap: within ioc . slow, shift. tr 

Both reading the hardware bootstrap of 9 words, and binary program loading in non-boot mode, are implemented here. 

2.A.2 The Flexowriter console: ioc . slow, shift. fw 

The Flexowriter, represented in ee9 by the user’s terminal window, has several unusual features: it includes an ‘edge- 
punched card’ reader; it outputs text in red ink; and is the source of FLEX interrupts, by means of which the operator gets 
the attention of Director. The edge-punched card reader is emulated using the external file “FWO”; see Users Guide for 
ee9, § 3.2. The red output is emulated, where the host OS supports it, by using ANSI terminal escape sequences to colour 
the displayed text appropriately. FLEX interrupts are emulated by typing control-C then RETURN. 


2. A.3 Magnetic tapes: IOC. fast .magtape 

Magnetic tapes are represented by Ada direct access files, using the Ada. Direct_IO library package, to allow selective 
overwriting of blocks. This is necessitated by the MWIPE and MGAP operations of the 1081-type tape deck. 

The “write permit ring”, which was a plastic band inserted into the tape reel concentrically with the hub, depressed a 
switch to enable the write heads. It is modelled by the file’s access permission. Making the file read-only simulates an 
absent ring, allowing operations that do not change the contents of the tape, and failing those that do. 

Each tape block, and each length of erased tape containing no data, is represented by one or more “slices”, a slice being a 
record in the direct access file. A slice has two components: a string and per-slice metadata. The string contains the Case 
Normal Latin-1 transliteration of all or part of a KDF9 tape data block. In the case of an erasure slice the string reserves 
space for possible future over-writing by data, but its contents are of no significance. The metadata is as follows. 

• Byte 0—whether the slice represents a data block (with code ‘D’), a length of tape erased by the MWIPE operation 
(code ‘W’), a length erased by the MGAP operation (code ‘G’), an even-parity tape mark (code ‘e’), or an odd-parity 
tape mark (code ‘o’). Tape mark codes do not appear within KDF9-native tape files. 


• Byte 1 —a code made up as follows: 

(a) if the block is ‘LBM’ marked; i.e. if it was written by a MLW/MLWE instruction instead of the normal 
MW/MWE instruction, and so responds positively to the MLB order: +64; 

(c) if this is the last slice of a multi-slice block: +8; and 

(b) if this is the first slice of a multi-slice block: +1. 


The second byte therefore takes the following possible values (decimal = octal = Latin-1): 


00 = 000 = NUL 
01 = 001 = SOH 
08 = 010 = BEL 
09 = 011 = HT 

64 = 100 = § 

65 = 101 = A 
72= 110 = H 
73 = 111 = I 


=+ no flags 

=+■ first slice of block 

=> last slice of block 

=> only slice of block (first and last) 

=> LBM flag 

=> first slice of block with LBM flag 
=> last slice of block with LBM flag 
=> only (first and last) slice of block with LBM flag 
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• Byte 2—the length of the string in this slice. An emulated MT block is represented by a number of consecutive slices 
such that the total length of their strings is sufficient to encompass the KDF9 data or erasure. The maximum string size 
has been set so that a MT block of 256 words, as used by POST, enjoys a space efficiency of 96%, while a short block 
containing one card image has a tolerable efficiency of 64%. 

This encoding makes the contents of a magnetic tape readily legible, e.g. using the Unix od command. Here is typical od 
output. It shows a label block; a second copy of it; some data slices; part of an MWIPE erasure, and an MGAP erasure. 

The labels are both single LBM-marked (‘I’) data (‘D’) slices, containingl6 (020s) characters: 


0000000 

D 

I 

020 

- 

0 

0 

- 

0 

5 

5 

2 

E 

F 

P 

B 

E 

0000020 

A 

A 

G 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

0000040 

* 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

0000200 

D 

I 

020 

_ 

0 

0 

_ 

0 

5 

5 

2 

E 

F 

p 

B 

E 

0000220 

A 

A 

G 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

0000240 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 


* 


The slice at offset 400 is the first (‘A’) of a long data block written with LBM marker. All but the last of its slices contain 
125 (*}’) characters : 


0000400 

D 

A 

} 

- 

0 

0 

- 

0 

5 

5 

2 

- 

0 

0 

- 

0 

0000420 

* 

5 

5 

2 

- 

0 

0 

- 

0 

5 

5 

2 

- 

0 

0 

- 

0 

The slices starting at 600 are neither first nor last (‘ @ ’), but still LBM marked: 






0000600 

D 

@ 

} 

5 

5 

2 

- 

0 

0 

- 

0 

5 

5 

2 

- 

0 

0000620 

* 

0 

- 

0 

5 

5 

2 

- 

0 

0 

- 

0 

5 

5 

2 

- 

0 

The slice at 63400 

is the last of the LBM marked block (‘H’). 

It contains only 

100 (‘d’) characters: 



0063400 

D 

H 

d 

0 

5 

5 

2 

_ 

0 

0 

_ 

0 

5 

5 

2 

_ 

0063420 

•k 

0 

0 

- 

0 

5 

5 

2 

- 

0 

0 

- 

0 

5 

5 

2 

- 

0063540 

0 

0 

_ 

0 

5 

5 

2 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

0063560 

* 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

At 63600 the MWIPE erasure (‘W’) begins: 












0063600 

W 

\0 

} 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

0063620 

* 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

Its last slice at 75600 is only 50 (‘2’) characters long: 










0075200 

W 

\0 

2 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

0075220 

* 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

At 75400 the MGAP erasure (‘G’) begins: 












0075400 

G 

\0 

} 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

0075420 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 

\0 


* 


2.A.4 Disc store: ioc . fast. fd 

Fixed disc space is represented by the direct access file FDO, using Ada.Direct_IO. The storage is treated as an array 
of data blocks without metadata content, one block of the file corresponding exactly to one KDF9 disc sector. 

2.A.5 Drum store: ioc.fast.DR 

Drum storage is represented by the direct access file DRO, using Ada. Direct_IO. The storage is treated as an array of 
data blocks without metadata content, one block of the file corresponding exactly to one KDF9 drum sector. The capacity 
of a maximum-size, 4-spindle drum system is small enough to read it into RAM at the start of emulation, act on it there, 
and write it back to DRO at the end of the run. 
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2.B Buffered I/O streams: host io 

Buffered I/O streams act as middleware between the KDF9 I/O operations and the POSIX I/O system calls that actually 
perform data transfers. They avoid having to do a system call for each KDF9 I/O operation. An output stream may be 
flushed to its output file, emptying its buffer. It is possible to connect a stream to several different files in succession, to 
enable the continuation-file feature; see Users Guide for ee9 . § 3.3. There is provision for injecting a given string into a 
stream; this is used by IOC. slow. shift. FW to support the edge-punched card reader. host_IO. put_EOL outputs 
a line terminator to a stream, in the form needed by the host OS; see §3 of this document. 

2.C POSIX thin binding: posix 

Only those system calls necessary for the implementation of ee9 are included. 

2.D User interface I/O: hci 

A fairly general logging feature is implemented, with the possibility of output to a selection of different kinds of log. At 
present logging to an external file, and logging to the user’s terminal are provided. 

2.E Logging: logging,logging.{panel,file), generic_logger 

The package logging declares a logging API, which is implemented in the packages logging.panel, for the 
terminal, and logging, file, for the external file log. The package generic_logger allows for the declaration of 
distribution lists, i.e. sets of log destinations. It is instantiated by HCI. The logging.panel package also provides 
simple prompt/response interaction for control of single-stepping, access to the debugger, etc. 

2.F Usage Of Ada Text I/O: Text_IO, Long_Float_Text_IO, Direct_IO, Enumeration_IO 
The standard text I/O packages are used as expedients in various places, such as logging. file, settings . 10, and 
IOC. slow, shift. FW, whenever a simple line-oriented facility suffices. Enumeration_IO is instantiated in the 
settings package for diagnostic_mode_IO, execution_mode_IO, and authenticity_mode_IO; and in 
settings. 10 to create colour 10 and width_IO for the GP-related options. Direct_IO is used to implement 
the IOC. fast .magtape. device. The ee9 package f ile_interf acing provides trivial open and close 
operations with exception handling for Ada. Text_IO file types. 

2.G Encapsulated PostScript (EPS) I/O: postscript 

A host_IO stream is used to write the EPS file that represents the roll of paper in the Graph Plotter. An EPS file includes 
a line near its start containing the maximum x- and y-coordinates used in the picture. These are not known until the end of 
the plot, so postscript. initialize_PS_output makes a note of the position of these strings in GPO, and 
replaces them with placeholders, postscript, finalize_PS_output seeks back to these placeholders and over¬ 
writes them with the actual values. 

2.H Graph plotter output: plotter 
Uses the package postscript. 

2.1 OUT-invoked I/O: KDF9.Directors 

In non-boot modes, ee9 approximates OUT 8, i.e. Director-spooled output, by immediate (unspooled) output to the 
ultimate destination device. KDF9 .Directors also handles programmed overlays (OUTs 1 and 2), mounting labelled 
magnetic tapes (OUTs 4, 6, 7 and 10), and allocating and deallocating slow peripherals (OUTs 5 and 6). 

2.J The Program Hold-Up Store: kdf 9 .PHU store 

Emulates the behaviour of the PHU registers when running in boot mode. 

2.K Settings file I/O: settings.10,settings.10.{colour_I0, width_I0}, 

settings.{diagnostic_mode_IO, execution_mode_IO, authenticity_mode_IO} 
Should be self-explanatory. 
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3. Host system dependencies: package os specifics, get o binary 

The only non-portable source code in ee9 is contained in the body of OS_specif ics. It has a single, OS-independent 
package specification, adaptation to the intended host OS being achieved by selecting a body file at compilation time. 

OS_specif ics offers the following simple API: 

• procedure make_transparent 
This does nothing on macOS and Linux. 

On Windows it makes a POSIX file read or write data transparently, without Microsoft’s conversion of line terminators, 
which would corrupt data such as KDF9 input in paper tape code. ee9 handles line terminators automatically, and does 
not need this ‘assistance’. 

To enable this mode, make_transparent calls _setmode with the 0_BINARY flag as defined in the fcntl.h 
header file. To make that accessible to the Ada program in a portable manner, we have the C function get_0_BINARY: 

#include <fcntl.h> 

int get_0_BINARY () 

{return (int)0_BINARY;} 

It returns 0_BINARY as a C int, and make_transparent simply passes that value on to _setmode. 

• function the_terminal_is_ANSI_compatible return Boolean 
This returns True on macOS and Linux; on Windows it returns False. 

• function UI_in_name return String 

This returns the interactive input device name appropriate to the host OS; i.e. /dev/tty for macOS and Linux, and 
CONIN$ for Windows. 

• function UI_out_name return String 

This returns the interactive output device name appropriate to the host OS; i.e. /dev/tty for macOS and Linux, and 
CONOUT$ for Windows. 

• function EOL return String 

This returns the line terminator appropriate to the host OS: LF for macOS and Linux, and CR LF for Windows. 

The ANSI-terminal escape codes for styling output text as red or black, in support of that feature of the Flexowriter, are 
declared in the package specification of OS_specif ics: 

• red_font_code : constant String := ESC & "[l;31m" 

black_font_code : constant String := ESC & "[22m" & ESC & "[39m" 

They are not accessed on any system for which the_terminal_is_ANSI_compatible returns False. 

4. Diagnosis and debugging 

ee9 is compiled with all of Ada’s language-mandated checks enabled. Experiment shows a negligible increase in 
emulation speed when they are all turned off. A second mode of compilation is provided by the mk9 shell command, 
which enables many more compile-time warnings, and activates the pragma Debug feature whereby a call to a 
diagnostic procedure is included in the object program only at option. There is also a run-time debugging flag, and the 
existing diagnostics (if actually included) provide output only when that flag indicates that the output is wanted. 

5. The ee9 and execute procedures 

ee9 is the ‘main program’; it checks and registers the command parameters, then calls execute, which contains the 
logic to co-ordinate program loading and instruction sequencing for the various execution modes. 

6. The a block and a2b utility programs 

a_block: outputs a program call tape, or ‘A block’, in KDF9 code; takes the ‘program reference number’ and ‘title’ 
from successive lines of standard input, and writes the result to standard output. 

a2b: reads from standard input in a stated code and writes it to standard output in another form. Conversions are 
available from raw bytes to paper tape code, between paper tape code and Latin-1, and from paper tape code to octal in 
half/word format with optional Q-store format and syllable format. 

For more information, see the accompanying document HOWTO. 

7. Odds and ends 

Can you think of anything else that needs explanation? If so, let me know: kdf 9 @ f indlayw. plus . com. 
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